Wow, I'm really on the ball here… Taking a look now, should have some feedback tonight.

And just because I'm a horrible person, I didn't take care of this last week. I have now though! Everything looks good. I do think you're right though that the zipper stuff (minus Zipper.scala) should be in its own package. I went through and implemented that change, which is now pushed to my djspiewak:zipper-breakdown branch. Let me know if there's anything I did wrong or something you want to change, otherwise I'll merge that branch into master this week.

Sorry again for taking so long!

I still have reservations about the readability of the whole thing, feels like the Zipper is being spread too thin between the numerous traits.
Also, before merging into master, the comments on #76 should be addressed (efficiency and usability).
I don't expect that the whole "zipper shifting" implementation is production ready, it was intended to be used only as a concept.

I still have reservations about the readability of the whole thing, feels like the Zipper is being spread too thin between the numerous traits.

That is the downside, to be sure. It really only makes sense if we have something like ZipperAxes that we're trying to enable. In other words, I wouldn't merge these changes separately; they belong together.

Also, before merging into master, the comments on #76 should be addressed (efficiency and usability).

Addressing…

I don't expect that the whole "zipper shifting" implementation is production ready, it was intended to be used only as a concept.

Gotcha. How would you like to proceed?

I can think of multiple possible bottlenecks in the code:

• Freely hashing and sorting paths.
• Using ZipperHoleMap for depth first iteration. As noted in the code it was not optimized for it.
• Redundant traversals of the tree: first collecting paths, then converting to values.

Of course, I don't have any benchmarks to prove that, but I do know that addressing these issues would make the shifting code even uglier than it's already is. And as I suck at optimizing things, I would prefer someone else giving it a try.

The first step should probably be making some sort of pseudo benchmark, just to get a feel of whether the performance is anywhere near acceptable.

Adding the operations discussed in #76.

The same comments about performance still apply.